|
|
|
|
|
|
|
Naming Subsystem Packages, Classes, and Objects |
|
|
|
|
|
|
|
|
Naming and coding standards aren't pervasive among newcomers to programming (and sometimes among seasoned developers who have managed to skirt the issue of implementing such standards). Microsoft's naming suggestions, of course, are fine, but I'll mention the ones that apply to classes and objects: |
|
|
|
|
|
|
|
|
Class names can start with a capital C (CAccount), as is the case with MS Visual C++, or you can opt to capitalize the first letter of the class, such as Account. Class names should be nouns and should adequately and briefly describe the types of functionality and attributes the classes will encapsulate. The same naming convention holds true for subsystems (or packages) that also are classes that are aggregates of one to many classes. |
|
|
|
|
|
|
|
|
Object names start with cls(clsAccount), or you can prefix object names with the or rep. Examples include theAccount or repAccount. |
|
|
|
|
|
|
|
|
Methods start with lowercase verbs (openAccount). Avoid using nouns for names of methods because you might confuse them with properties. Also, method names with verb forms accurately convey that an action will be carried out by the class (which is a noun). |
|
|
|
|
|
|
|
|
Class properties start with lowercase p (pName), unless you're able to differentiate between methods and properties (which is possible with the suggestion on naming methods). |
|
|
|
|
|
|
|
|
Implementation variables at the module level start with either a lowercase m or m_. If you use Class Builder, it will prefix implementation property variables with mvar. Implementation variables are variables used internally within a class. |
|
|
|
|
|
|
|
|
As for coding standards, whole books have been written on this topic (by authors including Jacobson, Booch, and Rumbaugh). At a high level, you use a mix of limited inheritance and delegation to express is a, has a, and uses relationships (discussed earlier in this chapter); delegation would be the default in your Visual Basic design models. You'll want to develop your interfaces (or protocols) so that they don't changeonly the implementation changes. You can have newer versions of an interface, meaning that during some overlapping period, you'll support both the old and new interfaces for compatibility, but compatibility isn't your immediate concern. You'll want to break your application model into nice categories (or subsystems) so that each developer has an island of classes with which to work. The idea here is that while these categories are being worked on, no two developers need to try to develop together. Only when the interfaces of each category |
|
|
|
|
|